Transactions between data processing systems that require the transfer of sensitive information are ubiquitous in the modem data processing environment. For example, such transactions may include electronic commerce retail transactions by individuals and businesses via the Internet, electronic funds transfers between financial institutions, or the communication of proprietary information between multiple installations of an enterprise. Protection of the sensitive information may be implemented by encrypting, or enciphering, the sensitive information, thereby shielding the sensitive information from unauthorized access. Modem cryptographic schemes rely on encryption algorithms that are publicly known, and rely on a secret encryption key (hereinafter simply “key”). See e.g., BRUCE SCHNEIER APPLIED CRYPTOGRAPHY SECOND EDITION 31-32 (1997). Enciphering an information set to be protected entails mathematically combining a key and the data constituting the information to be protected in accordance with the encryption algorithm. See e.g. Id. at 4-5. The recipient of the data recovers the information (the so-called plaintext) by mathematically combining a decryption key with the enciphered data. See e.g. Id. So-called symmetric encryption algorithms use the same key for enciphering the plaintext to generate the encrypted data and for decrypting the enciphered data to recover the plaintext. See e.g. Id. Asymmetric key encryption algorithm, which may also be referred to as public key algorithms, encipher the data to be protected with a first key, called the public key, and recover the plaintext with a second key, referred to as the private key. See e.g. Id.
Referring to FIG. 1, there is illustrated therein a schematic transaction between two users, A and B, illustrating the operation of a public key encryption scheme for protecting the sensitive information in the transaction. Note that one or both of users A and B need not be human users, users may also refer to data processing systems automatically implementing the transaction without human intervention. For example, a data processing system in a main office of a financial institution may automatically gather financial records from branch institutions at the close of business, without human intervention, and for security purposes, the transfer of such information maybe protected by enciphering the data. Similarly, in electronics funds transferred between financial institutions, which need not necessarily be branches of the same enterprise, may similarly be effected. Suppose, for example, in FIG. 1, user A needs to communicate sensitive information to user B. Encryption of the data is to be performed using a public key encryption algorithm, which is known to both user A and user B. Such algorithms are known in the data processing art. See e.g. Id at 466-67; 513-14 (discussing the RSA and Diffie-Hellman algorithms.) Each user has an associated private key (user A's, 102 and user B's 106) and a public key (user A's 104 and user B's 108). In accordance with the principles of public key cryptosystems, user A issues a request 110 to user B (as would be understood by an artisan of ordinary skill in the art, the data processing system associated with user A issues a request of the data processing system associated with user B) for user B's public key 108. User B sends a reply 112 to user A containing user B's public key 108. User A encrypts user A's message with user B's public key 108 and sends the encrypted message 114 to user B. User B then decrypts the message 114 using user B's private key 106 which is known only to user B. Note that user A's encrypted message 114 cannot be decrypted using B's public key. (FIG. 1 is meant to be illustrative of public key systems. More typically the public key algorithm is used to encrypt a secret symmetric key which is used with a corresponding symmetric key algorithm to encrypt the message, and the ciphertext and encrypted secret key are both sent to the recipient who first decrypts the secret key and uses it to recover the plaintext.)
However, user A cannot, without more, be certain that user B's public key reply message 112 has not been compromised in flight where, for example, a third-party substitutes its public key for user B's public key and not the public key of another. In other words, user A, without more, cannot be certain that the public key message 112 that it receives actually contains user B's public key. To authenticate user B's public key, the public key may be digitally signed by a party trusted by user A. (Authentication using digital signing is discussed, for example, in BRUCE SCHNEIER, APPLIED CRYPTOGRAPHY SECOND EDITION 34-41 (1997).) For the purposes herein, a file or data structure including a public key and associated digital signature (and possibly other information as discussed further below) may be referred to as a certificate. Trusted parties signing certificates may be referred to as certificate authorities (CAs)(Authentication of certificates may be provided by third-party commercial CAs. One such CA is Verisign). Thus, each user, such as user A and B in FIG. 1 maintain a database (often referred to as a keystore) of certificates which includes a certificate associated with the users' respective public key, as well as certificates associated with one or more certificate authorities, which, as will be discussed further herein below, may be necessary to create a “chain of authorities.” Typically, security enabled applications, web browsers, for example, usually include a keystore that includes certificates associated with one or more certificate authorities that are trusted parties of the provider of the web browser, or other application. Consequently, to accommodate authenticated key exchange, each user maintains a keystore 114 that includes a set of certificates needed recognize and resolve (or possibly, to generate) a chain of authorities. Such a keystore is schematically illustrated in FIG. 1B. In addition to the private key information 102, a portion of the keystore 116 contains the public information which includes a set of n of certificates 118, labeled CA1, CA2, CAn. Consequently, each user, maintains a set, or database of keystores associated with each security enabled application in the user's data processing system. This can create a significant administrative workload to maintain each user's keystore. For example, certificates may have a finite life time, and one or more certificates may expire without the user's knowledge, and additionally, individual users may not have the expertise necessary to update expired certificates. As a consequence, a chain of authentication may be broken, and the user unable to effect secure communications. Thus, there is a need in the art for apparatus and methods to centralize the management of certificate databases.